昨天說完那些卡最久的問題，今天來寫我最後做了什麼。

從七棒接力，變成五個階段

原本的流程是一條七棒接力。我最後把它拆成五個階段：

程式也照這個切法分成五支獨立的腳本，另外再加一支共用設定，放全域的參數和工具函式。我在那支檔案的開頭寫了一行給未來的自己看：

請勿把單一階段的邏輯寫在這裡；各階段請各自獨立檔案。

這個切法本身就是一個判斷。

我一開始其實想過按「功能」切：建表單的一支、寄信的一支、收資料的一支。看起來比較乾淨，重複的程式碼也比較少。

但這條流程的真實節奏不是這樣。它是一段一段往前推的，每個階段有自己的開放日、截止日、提醒節奏、還有自己的快照。按功能切的話，每次要調整某個階段，我都可能需要同時動好幾支檔案。

所以我選了比較「囉嗦」但比較好改的那一種。

先加個小小的但書

我講的這些做法，大概對工程背景的人來說都是基礎中的基礎，又或者其實有更好的做法(如果有的話也超級歡迎拜託跟我說)，因為我沒有很系統的學過，所以這些決定對我而言都很值得記錄起來，之後再回來回憶就能看到自己進步的過程。

出錯的時候，我選擇讓系統全部停下來

每一個會自動觸發的函式，我都包了一層保護：失敗就立刻寄錯誤信給我，同時在系統裡設一個「停擺」旗標。後續所有觸發器一開頭都會檢查這個旗標，只要是停擺狀態就直接跳過不跑。我排除問題之後，手動解除旗標，流程才會恢復。

我會這樣做，是因為在這條流程裡，上游錯了，下游跑得越順，傷害越大。

錯的資料會一路流下去，而且每一步都會寄信給真人。等發現的時候，要收回來的不只是資料，還有那些已經寄出去的信，而信是收不回來的，就算重寄也有可能造成收信人的混淆。

所以我選的是：寧可全部停住，也不要帶著錯誤往前跑。

但有一個地方我沒有這樣做

系統裡有一個每小時跑一次的輪詢，負責掃描誰交了、誰配對完成了。

這一支我特地沒有套上面那個保護。當時在程式裡留了一行註解：

輪詢是高頻任務，單次失敗不應停整個流程。錯誤寄信但不觸發停擺。

理由很單純：一個每小時跑一次的東西，如果因為一次網路問題就把整個系統停掉，那停機的機率會高到這個保護機制本身反而變成問題。

所以同一套系統裡有兩種錯誤處理策略，取決於那個動作的頻率和後果。

另外三件小事

這三個就真的是基本功了，快速帶過：

測試模式。 這套系統一跑起來就是上百封信寄給全公司，沒有測試模式我根本不敢按下執行。所以我放了一個開關，打開之後所有收件人都改成我的測試信箱、主旨加上 [TEST]、信的最上面加一行「原收件人：某某某」。最後那一行是關鍵，它讓我能驗證「這封信算出來該寄給誰」有沒有錯，而不是只驗證「有沒有寄出去」。

不覆蓋原始資料。 員工總表裡本來就有「去年的評分項目」(雖然不完整)，這一期收回來的新項目我沒有寫回去，而是另外開一個分頁。因為有些主管在選的時候要看得到去年選了什麼當參考，如果我把新的蓋上去，下一次就沒有參考了。

**所有東西都可以重跑。**建立表單的程式會自動跳過已經建過的，而且跑到快要碰到執行時間上限就自己停，再執行一次從中斷處繼續。這個主要是因為GAS的限制，因為要建上百份表單一定會撞到限制，與其想辦法讓它一次跑完，不如讓它可以安全地跑很多次。

我忘記的一件最重要的事

前面那些設計都是在講系統怎麼運作，但有件事我一開始差點忽略：真正要按下執行的人不是我，是人資。

我寫完就可以結案，他們卻要靠這套東西跑完接下來兩個多月，而且如果中間出了什麼事，要面對全公司的人也是他們。

我發現他們對於按下執行會感到不安，才想到這一層 當一個人要為結果負責、卻無法觀察和介入的時候，會這樣不安完全是合理的。

所以我另外做了一個控制面板分頁，針對的就是「觀察」和「介入」這兩件事。

觀察：現在跑到哪裡。 每一份表單的狀態都攤在上面：已建立、已寄出、已提交、已提醒過一次、截止未提交。誰還沒動，掃一眼就知道。

介入：他們可以自己動手。 每個動作都做成一個勾選框，勾下去就執行，執行完狀態回寫、勾選框自動取消。而且刻意分成兩區，「必做」的每個階段只有兩三顆，做完就可以放著讓系統自己跑；「自動執行、但可以手動覆寫」的那些收在下面，只有出狀況的時候才需要碰。

做完這個之後我理解到這是因為 自動化其實把「看得見」這件事拿掉了。

手動時代人資知道進度，因為每一封信都是他親手寄的；改成自動之後，流程跑在一個他看不到的地方，信有沒有寄出去？那個人到底填了沒？他不知道，只能來問我。

而「沒有人知道現在卡在誰身上」本來就是我們要解決的問題之一，如果自動化之後還是看不見，那只是把一種看不見換成另一種。

至於為什麼要讓他們能自己重跑：當然是因為如果只有我能按，那這套系統的可用性就等於「我在不在」，我可不想讓人資在流程卡住的時候，只能傳訊息問我。

四件沒有自動化的事

整條流程裡有四個地方是系統碰不到的：

1. 面談之後的共識分數。 系統只負責把欄位準備好、把時間排好，分數要人談完才填。

2. 上層主管的審核。 不只沒有自動化，連提醒都沒有(上一篇有提到過)。

3. 對分數有意見的時候怎麼處理。 原本有討論過要做「同意／不同意」的按鈕，後來拿掉了，改成請當事人直接去找對方談，系統只負責在時間到的時候鎖定版本。

4. 最後的結果通知。 時間到了不會自己發，要人確認過才觸發。

這四件事有一個共同點：它們的內容都不只是單純的「資料」，而是代表人跟人之間的一次交涉或責任歸屬。

系統可以安排時間、可以收發資料、可以提醒、可以鎖定版本、可以承載結果，但承載不了那個過程。

這四件裡面，第三件的討論過程我印象特別深。

那個「同意／不同意」按鈕的例子我印象特別深，拿掉它的理由跟技術完全無關，是因為我跟人資討論的時候發現兩件事：

第一，「不同意」這三個字太強硬了。 分數是上層主管改的，要下層按一顆寫著「不同意」的按鈕，那個動作本身就帶著反駁的意味。我們的結論是就算做了，大概也不會有人敢按。

第二，按鈕只能表達結果，不能表達理由。 而這件事真正的重點恰恰在理由，你為什麼覺得這個分數不對？一顆按鈕承載不了這個。

既然不同意之後終究要當面談，那這顆按鈕就是多餘的。

最後

寫完之後我覺得我做的其實不是「把考核自動化」。

我做的是把那條接力賽的交棒動作"透明的"自動化：誰該動了、動了沒有、資料從上一棒怎麼變成下一棒的輸入、時間到了怎麼收，都能讓人資在自動化的同時一目了然。